Looks good, only one thing to fix is:

can you just store it in the last 2 short retain channels? Just as I said on forum.... I must find the topic, I think it was there: https://www.elektroda.com/rtvforum/topic4045136.html

Thank you @openshwprojects, I roll back to the original 12.

I'm debugging and facing an issue that was solved by @2Fblob implementation. His solution was to invert the energy capture to negative when the power on that second is negative. The problem with this implementation is that can lead to large measurement errors. He also tried to identify the flow of the current but apparently, it's not working properly: https://github.com/2Fblob/OpenBK7231T_App/blob/afbbf52fbf02ee9117984b42fb747b1aca2d6663/src/driver/drv_bl0942.c#L149

Maybe you can help with this, The i_rms properly give negative values which makes negative Power correctly https://github.com/openshwprojects/OpenBK7231T_App/blob/main/src/driver/drv_bl0942.c#L130

However, the cf_cnt always returns a positive value which always makes positive values on the energy variable. https://github.com/2Fblob/OpenBK7231T_App/blob/afbbf52fbf02ee9117984b42fb747b1aca2d6663/src/driver/drv_bl0942.c#L145

Do you have any ideas on how to make this measurement more accurate? A simple solution would be to invert the value if the i_rms is negative, but it would make incorrect measurements in my understanding.

The instantaneous power (watts) returns a positive or negative value, which I am using to put a sign on the value retrieved by cf_cnt. Similar to the current as you mentioned, but beware of using the current, because unless PF=1 the current may have a different sign of the power.

I did try, on early versions of the code, to use the actual flag that monitors the direction of the last energy retrieved. What I found was that on phase controlled or half wave rectified loads we were getting mixed results and the calculations werent correct, because we were both consuming and exporting within one mains cycle. But I did notice that the instantaneous power, because its averaged over a period, returned the correct sign. I didn’t note any significant errors - Do you have any data showing measurement errors?

I do have a different problem as some devices are wired backwards, so they report power as positive or negative for a given direction. We need a flag to invert this, so the output is consistent. At the moment, my code assumes positive power = consumption, negative power = generation. That is to keep compatibility with the statistics feature, where consumption is measured (original code discards negative values, so we want to keep that unchanged).

On the retain channels I havent found an easy way to save and retrieve without making significant changes to the code, because loops are used to read those memory locations, so its important they keep the memory locations unchanged. Ill write about that in more detail once I'm done with the bug changes.

Another question, changing the order of the ENERGY_METERING_DATA would make it more compatible with devices running current firmware?

@2Fblob please, don't get me wrong, I'm not an expert. In my understanding, the power and energy are registered every second and the instant power can change from positive to negative during the snapshot of the measurement, and the energy be accounted to the wrong side at that moment. Does it make sense?

You're not wrong, but unfortunatelly the only way to get super accurate results is to measure at each half cycle, which is not really practical. Altough as I mentioned I didnt notice any significant error in real life, because the watt register is averaged over a period of time (It was very accurate with half wave rectified loads, for example).

Here's some detail from the datasheet.

I think I recall its averaged over 800mS on the code.

Thank you for the clarification @2Fblob. In that case, the code is working stable on my device. No crashes or disconnections. Please, feel free to add or change anything to improve the code.

I will only make one test inverting the order on the ENERGY_METERING_DATA to see if will break history compatibility.

@openshwprojects, I changed the order of the elements on the ENERGY_METERING_DATA putting TotalGeneration by last. In my testing, the TotalConsumption was preserved on the OTA update in this case.

@2Fblob, I kept running for the entire day and indeed didn't see much difference from the other measurements like you anticipated, thank you.

Hi,
Can you please take a look into #1273 ?

I propose several structure changes in power-measurement modules, you might be interested in.
Thanks.

Hello @rpv-tomsk,

The idea seems very good, congrats on the initiative.

Now it depends on how @openshwprojects wants to proceed to merge these implementations.

There is also #1211 working on the same implementation.